No e2e coverage existed to confirm that pod spec fields set on a BatchTrigger (tolerations, annotations, nodeSelector, securityContext, initContainers, resource limits, env vars) actually appear on the created pod.

New fixture: fixtures/pod-spec.yaml

A BatchTrigger with a pod template exercising a broad set of fields:

• Metadata: static + templated annotations and labels
• tolerations, nodeSelector, securityContext (runAsUser/runAsGroup/fsGroup)
• serviceAccountName, initContainers
• Container env (static + templated), resources.limits/requests

New test: "Should apply all pod spec fields to the generated pod"

Sends a message with pod_label, annotation_value, and env_value template variables, then asserts each field is present on the resulting pod:

Expect(pod.Spec.Tolerations).To(ContainElement(corev1.Toleration{
    Key: "dedicated", Operator: corev1.TolerationOpEqual,
    Value: "batch", Effect: corev1.TaintEffectNoSchedule,
}))
Expect(*pod.Spec.SecurityContext.RunAsUser).To(Equal(int64(1000)))
Expect(container.Env).To(ContainElement(corev1.EnvVar{Name: "DYNAMIC_ENV", Value: envValue}))
Expect(container.Resources.Limits[corev1.ResourceCPU]).To(Equal(resource.MustParse("100m")))

Also adds test-batch-runner-pod-spec to the LocalStack queue creation step.